<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="umsroot.css">
<TITLE>
Special Compiler Features
</TITLE>
</HEAD>
<BODY >
<A HREF="umsroot033.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="umsroot028.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="umsroot035.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2 CLASS="section"><A NAME="htoc78">6.6</A>&nbsp;&nbsp;Special Compiler Features</H2><UL>
<LI><A HREF="umsroot034.html#toc46">Compiling Non-Textual Source</A>
<LI><A HREF="umsroot034.html#toc47">Mode Declarations</A>
<LI><A HREF="umsroot034.html#toc48">Inlining</A>
<LI><A HREF="umsroot034.html#toc49">Clause Expansion</A>
</UL>


<A NAME="toc46"></A>
<H3 CLASS="subsection"><A NAME="htoc79">6.6.1</A>&nbsp;&nbsp;Compiling Non-Textual Source</H3>
A characteristic feature of Prolog and ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> is, that programs can
be represented as data structures in a straightforward way.
The compiler therefore provides the
<A HREF="../bips/kernel/compiler/compile_term-1.html"><B>compile_term/1</B></A><A NAME="@default258"></A>/
<A HREF="../bips/kernel/compiler/compile_term-2.html"><B>compile_term/2</B></A><A NAME="@default259"></A>
interface, which allows to compile a list of terms. The compiler
interprets these as clauses, directives and queries, similar to program
source being read from a file. For program generators, it is therefore
not necessary to create a textual representation of generated code -
the data structures can be compiled directly.<BR>
<BR>
There are the following minor differences between compilation from
textual sources and term compilation:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Module directives are not supported - to compile code into a certain
 module, use the construct compile_term(Clauses,Options)@Module, and use
 <A HREF="../bips/kernel/modules/create_module-1.html"><B>create_module/1</B></A><A NAME="@default260"></A>
 to create modules beforehand if necessary.
<LI CLASS="li-itemize">Include directives do not make sense and are not supported.
<LI CLASS="li-itemize">No end-of-compilation events are raised - compile_term/1 behaves more
 like the compilation of an included file in this respect. This implies
 that discontiguous predicates are not supported.
</UL>
A variant of compile_term/2 is
<A HREF="../bips/kernel/compiler/compile_term_annotated-3.html"><B>compile_term_annotated/3</B></A><A NAME="@default261"></A>
which takes source terms with source position annotations.
This can be used when compiling auxiliary code within inlining/goal
expansions transformations, without losing the source position information
which is needed by the debugger.<BR>
<BR>
<A NAME="toc47"></A>
<H3 CLASS="subsection"><A NAME="htoc80">6.6.2</A>&nbsp;&nbsp;Mode Declarations</H3>
<A NAME="@default262"></A>
<A NAME="@default263"></A>
Mode declarations are a way for the user to give some additional
information to the compiler, thus enabling it to do a better job.
The ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> compiler makes use of the mode information mainly to
improve indexing and to reduce code size.<BR>
<BR>
Mode declarations are optional. They specify the argument instantiation
patterns that a predicate will be called with at runtime, for example:
<BLOCKQUOTE CLASS="quote">
<PRE CLASS="verbatim">
:- mode p(+), q(-), r(++, ?).
</PRE></BLOCKQUOTE>
The possible argument modes and their meaning are:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B>+</B><DD CLASS="dd-description"> - The argument is instantiated, i.e. it is not a variable.<BR>
<BR>
<DT CLASS="dt-description"><B>++</B><DD CLASS="dd-description"> - The argument is ground.<BR>
<BR>
<DT CLASS="dt-description"><B>&minus;</B><DD CLASS="dd-description"> - The argument is not instantiated, it must be a free variable
without any constraints, especially it must not occur in any other
argument and it cannot be a suspending variable.<BR>
<BR>
<DT CLASS="dt-description"><B>?</B><DD CLASS="dd-description"> - The mode is not known or it is neither of the above ones.
</DL>
Note that, if the actual instantiation of a predicate call violates
its mode declaration, the behaviour is undefined.
Usually, an unexpected failure occurs in this case.<BR>
<BR>
<A NAME="toc48"></A>
<H3 CLASS="subsection"><A NAME="htoc81">6.6.3</A>&nbsp;&nbsp;Inlining</H3>
<A NAME="@default264"></A>
<A NAME="@default265"></A>
<A NAME="@default266"></A>
To improve efficiency, calls to user-defined predicates can be
preprocessed and transformed at compile time. The directive
<A HREF="../bips/kernel/compiler/inline-2.html"><B>inline/2</B></A><A NAME="@default267"></A>, e.g.
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
:- inline(mypred/1, mytranspred/2).
</PRE></BLOCKQUOTE>
arranges for mytranspred/2 to be invoked at compile time for each 
call to the predicate mypred/1 before this call is being compiled.<BR>
<BR>
The transformation predicate receives the original call to mypred/1
as its first argument, and is expected to return a replacement goal
in its second argument. This replacement goal replaces the original
call in the compiled code. Usually, the replacement goal would be
semantically equivalent, but more efficient than the original goal.
When the transformation predicate fails, the original goal is not
replaced.<BR>
<BR>
Typically, a predicate would be defined together with the corresponding
inlining transformation predicate, e.g.
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
:- inline(double/2, trans_double/2).

double(X, Y) :-
        Y is 2*X.

trans_double(double(X, Y), Y=Result) :-
        not nonground(X),    % if X already known at compile time:
        Result is 2*X.       % do calculation at compile time!
</PRE></BLOCKQUOTE>
All compiled calls to double/2 will now be preprocessed by being passed
to trans_double/2.
E.g. if we now compile the following predicate involving double/2
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
sample :-
        double(12,Y), ...,  double(Y,Z).
</PRE></BLOCKQUOTE>
the first call to double will be replaced by <CODE>Y=24</CODE> while the
second one will be unaffected. The code that the compiler sees and
compiles is therefore
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
sample :-
        Y=24, ...,  double(Y,Z).
</PRE></BLOCKQUOTE>
Note that meta-calls (e.g. via
<A HREF="../bips/kernel/control/call-1.html"><B>call/1</B></A><A NAME="@default268"></A>) are never
preprocessed, they always go directly to the definition of double/2.<BR>
<BR>
Transformation can be disabled for debugging purposes by adding
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
:- pragma(noexpand).
</PRE></BLOCKQUOTE>
to the compiled file, or by setting the global flag
<BLOCKQUOTE CLASS="quote"> <PRE CLASS="verbatim">
:- set_flag(goal_expansion, off).
</PRE></BLOCKQUOTE>
<A NAME="toc49"></A>
<H3 CLASS="subsection"><A NAME="htoc82">6.6.4</A>&nbsp;&nbsp;Clause Expansion</H3>
Before compilation, the compiler also performs clause macro expansion
(<A HREF="../bips/kernel/syntax/macro-3.html"><B>macro/3</B></A><A NAME="@default269"></A>. This includes
the DCG grammar rule expansion (section <A HREF="umsroot069.html#dcg">12.3</A>).<BR>
<BR>
<HR>
<A HREF="umsroot033.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="umsroot028.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="umsroot035.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
